Traditionally great deal of actual capacity planning work has been done manually without comprehensive automation. Especially in large scale DBMS_SYSTEM environments it has typically been challenging, inaccurate and time consuming task to plan new TARGET_SYSTEM CONFIGURATION for existing SOURCE_SYSTEM CONFIGURATION to be upgraded, migrated and/or consolidated.
Also, even on existing SYSTEMS where there is some CAPACITY_PLANNING automation implemented, it does not provide effective method for DBMS_INSTANCE and/or DATABASE level CAPACITY_PLANNING and SCENARIOS within the whole LOGICAL_TOPOLOGY of the SYSTEM according to the DATABASE bound capacity. Some of those solutions are able to analyze one SOURCE_SERVER capacity at time but cannot effectively solve overall CAPACITY_PLANNING scenarios wherein minimal overall capacity can be planned to be used because existing capacity needs can be calculated, harmonized and therefore optimized as one entity, not in many little pieces at a time.
Even in smaller environments, there is almost endless amount of different possible TARGET_SYSTEM CONFIGURATION SCENARIOS in terms of HARDWARE, SERVERS, VIRTUALIZATION, NETWORK, STORAGE, CLOUD SERVICES and such. A method based on substituting one distinct SERVER, DBMS_INSTANCE or DATABASE at once is rarely optimal solution in terms of TARGET_SYSTEM capacity needs. All this often leads in following problematical use cases:
CAPACITY_PLANNING is split into smaller, more easily manageable sub projects focusing in one to few SERVERS at a time instead of all SERVERS (can be anything from distinct SERVERS up to hundreds of thousands of SERVE RS in real life scenarios) because planning whole TARGET_SYSTEM capacity needs at once has either been too complex problem to solve or there has not been insight of an advantage in planning the TARGET_SYSTEM at once from a larger set of SOURCE_SYSTEM data or from whole SOURCE_SYSTEM data.
Such a method easily causes a great overhead in total on RESOURCES such as hardware such as network devices, host servers, their respective RAM configuration, overall cpu capacity needs, operating system, software, SERVERS, DATA_CENTER space, electricity consumption, running costs and such when these smaller sub projects are being implemented one by one over time. And, in those scenarios wherein overall capacity from SOURCE_SYSTEM is being planned into a TARGET_SYSTEM in such way, the method itself is not able to solve capacity optimization over time in optimal fashion by organizing old data in such way it will consume the least overall capacity needed.
Instead, in many typical use cases database architects have been using simple and therefore inaccurate deduction like calculating existing average capacity needs over last year and giving it some growth estimate over wanted TARGET_SYSTEM lifecycle and proceeding CAPACITY_PLANNING estimate for each SOURCE_SYSTEM SERVER based on this type of thinking. Such a CAPACITY_PLANNING method is problematical in many ways and may easily end up with 30% or even more excessive TARGET_SYSTEM overall capacity compared to a CAPACITY_PLANNING method defined in this invention.
Another weak point for abovementioned simple CAPACITY_PLANNING method is it is not able to fit existing capacity in form of TIME_SERIES and therefore is more vulnerable for out of capacity situation of which later on defined a more precise illustration. That's why it is relatively common for Database Architects to put a significant SAFETY_MARGIN for their TARGET_SYSTEM capacity estimations, typically 30-50% which makes such a method even worse.